Computer databases have long been used to conveniently and efficiently organize, store, and access vast amounts of information and data. Any business or organization that finds it necessary to work with large amounts of data often makes use of computer systems configured with one or more databases. Databases are essential to managing large amounts of data in an efficient and meaningful manner. Data comes in a myriad of formats, content, relationships, and applications. Databases can be used to store information related to the fields of accounting, financial records, banking, manufacturing, inventory, distribution, business records, human resources, customer information, health care, medical records, biotechnology, and government records, just to name a few.
The structure of known databases range from simple 2-dimensional flat files to more complex relational databases. A flat file typically contains a number of records and a fixed number of fields per record, each field having a value stored therein. The records may be fixed or variable in length. In a simple customer contact database, using a flat file format, each record may contain customer name, address, phone number, and e-mail address. There is one record for each customer. In order to search the flat file database, the system typically begins at the first record and examines the records one by one until the desired information is found. In most cases, there is no relationship between different records of the flat file database. Flat files are useful for a relatively small number of records and limited amount of information per record. For flat files with many records, one or more supporting index files may exist to decrease the searching time.
In other applications, which require a larger number of records and more information per record, flat files become impractical. Relational databases are better suited for larger, more complex interrelated information systems. Common relational database products are SQL Server, Access, and Oracle Database. A relational database may contain several files, each having a different structure, which are related by linkages. Each file may have its own unique format, and the files will differ in content, scope, organization, and structure. In the banking business, each customer will have personal information and financial records stored in a number of accounts. The customer may have accounts for checking, savings, loans, credit cards, investments, etc. In a simple example, customer A has a main record and several different account records. Each account record contains a link to the main account. The identification number is the link or relation between the main record and the individual account records. Actual banking databases will have much more complex relational databases and interrelated data structures.
The data structure of a relational database must be defined and created before it can be used. The definition of the data structure is known as the schema of the database. A computer program uses the schema to build the basic database file structures and interrelationships between the many different data file structures. Another set of application software and computer programs is written and customized to the specific database structure, as defined by the schema, to manage the data in the database. The application software is used to store data in the database, search for data in the database, retrieve previously stored information, and update information. The relational database uses organizational techniques such as hashing and B-trees, to efficiently find specific records and retrieve the desired information. The application software is designed to function with only specific or similar schema structures.
Relational databases are for the most part rigid in terms of structure and usage. For example, each customer account record will have a specific format with fields for the respective informational content, as defined by the schema. The various customer account records or database files will each have their own custom structure, according to the information related to the account. A checking account record may contain fields for account number, date, check number, transaction number, amount, payee, etc. If the bank decides it needs to add another field to the checking account record, say to comply with a new banking regulation or to offer a new service to the customer, then the schema may have to be redefined and the data structure reformatted to accommodate the new field. Moreover, the application software would have to be modified or rewritten to read, write, and search with respect to the new data field and perform the necessary computations and reporting functions using the new data field.
The magnitude of the task necessary to make such changes to existing relational database structures can be enormous in terms of time and cost. The database may have to be taken off-line to make the changes, which often cause disruption to daily operations. The changes must be thoroughly tested to confirm the integrity of the modified system. Nonetheless, given the complexity of large databases, any revision creates the real opportunity for mistakes in the new structure, relationships to prior structures, and application software code. Many times the mistakes are not found until after costly errors are detected during normal operations, sometimes as a result of customer complaints, which is an undesirable outcome. The reality is that database administrators rarely welcome changes to known working systems and often hold their breath as the system comes back on-line.
The problem can be magnified by major system changes to the database. In most cases, each bank has its own custom database structure and application software. If two banks merge, then one database system is usually converted to become compatible with the other. This type of integration is extremely complex. Not only will the database structures be different, but information content per field may be incompatible. For example, one bank may use one field for the transaction number with a given format. Another bank may split the transaction identifier into multiple fields with an entirely different format. Specialized programs have to be written to perform the conversion with careful processing and consideration of many special circumstances. The opportunity for problems is high, and major database conversions are rarely error-free. Patches to correct previous mistakes can introduce additional errors. The error detection process and fine-tuning can go on for some time until the new database has regained its previous level of data integrity and error-free operation.
Another problem for relational databases is the potential for covert, intentional, and unintentional corruption of data. While many databases have some form of security screen surrounding data, most data security systems are still vulnerable. Hackers have been known to gain access. In general, it is difficult to detect intentional corruption of data solely by examining the records themselves. New information replaces the prior information and the history is lost. While databases are routinely backed-up, the recovery process is time consuming and costly. Problems are detected only some time after the corrupting event.
A need exists for a new database structure which is easy to maintain, repeatable, expandable, transportable, and maintains historical information.